Libris Britannia 4/science library(b).zip/science library(b)/INFO/DOSTIPS3.ZIP/DOSSBDRS.TXT

Text File | 1985-11-24 | 22KB | 383 lines

                    The PATH to Your Command
        (PC Magazine Vol 3 No 6 Apr 3, 1984/Peter Norton)

     When we give DOS a command, such as FORMAT or CHKDSK, it has to
find the program that will carry out that command.  Several of the most
fundamental commands, such as DIR and DATE, are built into COMMAND.COM.
These are called the internal commands.  If the command that we've
asked DOS to perform is internal, DOS's command interpreter has the
program that's needed right at hand, so it looks no further.
     If DOS doesn't find a command in its internal table, then it looks
on disk for a command file (a file with an extension of COM, EXE or
BAT) with the same name as the command we entered.  Here is where DOS
2.x is different from DOS 1.x.  DOS 2.x allows us to use the PATH
command to look in several different places for a command file.  The
PATH command lets us instruct DOS to hunt for our command files in as
many places on disk as we want.  Without a PATH command, DOS looks for
a command where it has always looked, in the current directory of the
current drive.
     Suppose we have a PC with a drive C configured.  We might keep
many programs, particularly DOS programs like CHKDSK, all in one
directory.  Let's say the programs are kept in a directory named PROGS;
the full path name to PROGS would be C:\PROGS.
     Ordinarily, if we are working in another directory, we wouldn't be
able to get to our programs.  But if we entered a PATH command, we can
tell DOS to look to our PROGS directory:
          PATH C:\PROGS
Once the PATH command is entered, DOS will keep track of it and look to
the directory we've specified for command files.  If we've switched our
current directory somewhere else, DOS will still be able to find and
execute any programs in the PROGS directory.
     This operation works even if we've switched the current drive.
Say we wanted to work with a diskette for a moment, and we've switched
out current drive to the A: drive.  With the PATH command show above,
DOS will still be able to find and use all the programs in our PROGS
directory.
     To make sure that the PATH command works right, it's important to
specify carefully the full pathname of the directory including its
drive letter.  Suppose we'd left this part off in the previous example,
so that the PATH was just \PROGS.  When we switched our current drive
to A or any other drive, DOS would search for a PROGS directory on that
drive, since the PATH command didn't specify which drive to look at.
     There's even more power to the PATH command.  We aren't limited to
telling DOS to search a single directory path -- we can give lots of
paths in the PATH command.  To do this, we just list all the directory
paths we want DOS to search separated by semicolons, for example, two
directories:
          PATH C:\PROGS;C:\OTHERS
After we enter that command, DOS will go looking for commands in both
directories in the order we gave them.  In this example, DOS will
search the PROGS file before it searches OTHERS.  As soon as it finds
the command program we've asked for, it will run it.
     We can put lots of paths in the search if we want to.  Although I
don't think that it's a good idea to scatter programs through a bunch
of directories, if your programs are scattered you can still use them
all conveniently by setting up a PATH command that tells DOS to look
through all of them.
     Another use of multiple paths is that the paths we tell DOS to
search can be on different drives.  This turns out to be one of the
best and handiest uses of the PATH command.
     While we might not have our programs spread out in several
subdirectories, we might have them in several different drives.  There
are lots of good reasons for doing this.  For example, if you use a
RAMdisk, you could load your most frequently used programs into the
RAMdisk and use the PATH command to have DOS try to find programs there
first.  If your RAMdrive is drive C and you usually use a disk in
drive A for any programs that aren't loaded into the RAMdrive, the PATH
command you'd use is:
          PATH C:\;A:\
With that PATH, DOS will check the RAMdrive first, and then the A:
drive.
     Before DOS searches through any directories that we've asked it to
search with the PATH command, it searches through the current directory
in the current drive. This has two practical results.  First, there's
no need to put our current directory into the search path.  DOS will
look at the current directory anyway; putting it into the path will
just make DOS search there twice and slow things down.  Second, since
the current directory is searched first, we can't use the PATH command
to override any programs in the current directory.  If you have a
program in the current directory, but you want to use another version
of it in another directory you'll have to give it another name, because
DOS will use the copy of the program in the current directory before it
looks elsewhere.
     Article continued in:

                  Keeping Subdirectories Simple
       (PC Magazine Vol 3 No 7, Apr 17, 1984/Peter Norton)

     Subdirectories are best used by people who use hard disk systems.
The extra work DOS goes through to use subdirectories on floppies makes
the process painfully slow.  Subdirectories are for dividing files into
groups, and nothing else.
     Should you put subdirectories under subdirectories?  Only if you
like to suffer.  The concept of using a complex tree structure is
appealing.  We logically group our files in master subdirectories and
subsidiary sub-subdirectories.  We build a tree structure to match the
logical relationship of our files.  There are two main problems with
using a complex tree-structure directory.  There's a performance
problem: DOS has to do a lot more work to thread its way through all
that foliage.  There's also a human problem.  It's a lot harder to keep
track of directories for subdirectories under subdirectories.  Although
the TREE command is there to help, it's of little practical assistance.
Put all your subdirectories under your disk's root directory, not under
one another.  Giving them distinct names is another thing.  A distinct
signature for subdirectory names, such as .DIR or .SUB, is recommended.
If all your subdirectories have the same distinct filename extension,
then you can easily call up a list of all of them with the command:
          DIR\*.SUB
     If you'd like to have them sorted alphabetically, use a pipeline
command like this:
          DIR\*.SUB | SORT | MORE
     I have devised a system to easily call up the subdirectory list.
I put the pipeline command shown above into a batch command file named
DD.BAT.  That way, by entering DD (Display Directories, as I call it),
I get a sorted list of my subdirectories.  At the moment I have 26
subdirectories, and this batch command helps me keep all of them
straight.
     The real question is how to group files in subdirectories and then
how to work with them.  The first rule is to subdivide as little as
possible.  Put everything that you don't really need to separate out
into one catchall directory, such as your disk's root directory.  This
would include all the standard DOS programs and any miscellaneous
programs that you don't need to keep track of separately.  My root
directory, for example, has 145 files in it; almost every program I
have is in there.  I don't need to look at them; I just want them
working for me.  So I stick them all into my root directory and forget
about them.  Remember that the PATH command keeps the programs in your
catchall directory on tap at all times.  My catchall directory is the
root directory of drive C.  I keep the PATH command set to C:\, which
provides me with immediate access to every program I have stored there,
no matter what drive or subdirectory I'm using.
     Your catchall directory is dedicated to holding everything you
never want to see.  It should be filled with programs that you use but
that you wouldn't need a list of.  The catchall directory is a
convenient place to dump things that you don't need to keep track of;
subdirectories are what you use for things that you do need to keep
track of.
     The next rule is some programs deserve their own distinct
subdirectories.  When they do, separate them from your catchall
directory.  When you expect to have more than one version of a program,
for example, and you want to keep both the old and new versions, use a
subdirectory.  Or when a series of programs works together and you want
to be able to see a list of them to remind you of their names, having a
tight little subdirectory of all the programs in one working system
makes it easier to use them.  For example, I keep my accounting system
in a subdirectory and I can quickly remind myself of all the program
names with the command:
          DIR\GL\*.BAS
(BAS, because the programs are written in BASIC.)
     Whenever you have programs separated out into subdirectories use
the PATH command to make sure that they are on tap at all times.
Suppose that your catchall is the root directory of your hard disk,
drive C, and you've got two program subdirectories, NORTON and C-TOOLS.
In addition, you load some programs into a RAM drive (drive D) for
faster access.  Here's your ideal PATH command:
          PATH D:\;C:\;C:\NORTON;C:\C-TOOLS
     There is one more situation in which it makes sense to separate
out programs into their own subdirectories -- when the programs use
their own data files in addition to the files that we want them to work
on.  Examples of programs like this are spelling checkers, which use
dictionary files, and sophisticated programs like Lotus 1-2-3 that
reads program overlay files and also uses initialization or profile
files.  Programs like these create a special situation that complicates
our work.

-----------------------------------------------------------------
                    The Stubborn Subdirectory
              (PC World April 1985 The Help Screen)

     To delete (remove) a subdirectory, the directory must not contain
any files or other subdirectories, and the current directory must not
be the one destined for deletion.  Begin by making the subdirectory to
delete the current directory [CD\directory-name].  Next do an ERASE *.*
to delete all the file entries that this directory contains.  Follow
this by taking a directory listing [DIR] to check that this directory
does not include any subdirectory entires.  The only entries left in
this case are the period, which indicates that this is a subdirectory,
and the double period, which DOS uses to locate the directory's parent
(the higher-level directory that encompasses this directory).  Then
change the current directory to the root directory [CD\] and execute
RD\directoryname.  Problem:  You receive the standard error message,
"Invalid path, not directory, or directory not empty."  What prevents
removal of this subdirectory?
     The steps are essentially correct.  But let's review the possible
errors in the DOS message:
     Directory not empty.  Although the DOS manual notes that ERASE*.*
deletes all files in the current directory (and that ERASE [drive:]path
deletes all the files in the path-specified directory), ERASE does not
delete hidden or system files.  Hidden and system files are excluded
from directory listings and from the "number of files" report in a
listing's last line.  Hidden and system files within a subdirectory are
difficult to delete without a special utility that can list such files
and change their attributes, converting them into "normal" (ERASEable)
files.
     Not directory.  In most cases, this error message refers to a
misspelled directory name.  It's also possible that a directory name
may have been altered to include a nondisplayable character, but that
is rare.
     Invalid path.  To locate a specific subdirectory, a DOS command
must be supplied with a path parameter that includes, in the correct
order, every subdirectory level, from either the root directory down
to the desired directory; the current directory down to the desired
directory; or the current directory up to a common ancestor and then
down to the desired subdirectory.
     If DIR-22 is the current directory and you want to remove DIR-212,
you could begin the path parameter with the root dir:
          C>CD <Enter>
          C:\DIR-22
          C>RD\DIR-21\DIR-212 <Enter>
     Alternatively, you could use the double period to ascend the path
from the current directory to a common directory, then specify the path
down from that directory:
          C>CD <Enter>
          C:\DIR-2
          C>RD DIR-21\DIR-212 <Enter>
     Instead of DIR-22, suppose the current directory is DIR-2.  In
that case, to remove DIR-212, a descendant of the current directory,
you may begin the path parameter with the appropriate child of the
current directory:
          C>CD <Enter>
          C:\DIR-22
          C>RD..\DIR-21\DIR-212 <Enter>
     Note that in each example the path parameter includes every
subdirectory name along the specified path.  Even if the root directory
were the current directory (instead of DIR-22) in the first example,
the path parameter zDIR-212 would be invalid because the intermediate
subdirectories have been omitted.
     It may be that the stubborn directory is not a child of the root
directory, in which case the command RD\directoryname omits the
intermediate subdirectory or subdirectories.

-----------------------------------------------------------------
                          Subdirectory Magic
          (PC Magazine Vol 4 No 10 May 14, 1985 User-to-User)

     DOS allows users to organize their files by pigeon-holing
everything away in nested subdirectories.  But DOS doesn't provide a
convenient way to rename directories.  To rename a directory, most
users create a new one with the new name, copy all the files into it
from the old one, and remove the old one -- or they take advantage of
special utilities like those published in PC Magazine's Programming
Column.  Advanced users can zip into the disk directory with DEBUG and
revise any filename.
     However, DOS 3.0 users can change any subdirectory name simply by
going into BASIC 3.0 and using its NAME command.  For instance, to
change the name of the DOS subdirectory \SALT into \PEPPER, all a BASIC
3.0 user need type is:
          NAME "\SALT" AS "\PEPPER"
Note that this works only in BASIC 3.x.  A subdirectory name is handled
very much like other filenames, except that byte 11 of its directory
lising is a hex 10.  Incidentally, by using DEBUG, you can hide the
subdirectory listing by changing this byte from a &H10 to a &H12.

-----------------------------------------------------------------
             Redirecting Files and Renaming Subdirectories
           (PC Magazine Vol 4 No 12 June 11, 1985 PC Tutor)

     You can re-direct a file from one subdirectory into another
without copying and erasing by using BASIC's NAME ...AS ... command
in director (nonprogramming mode).  Enter:
          NAME"\dir1\file.ext"
          AS"\dir2\file.ext"
The RENAME command in DOS won't work because it will not accept a
second path.  Is there a patch (using DEBUG) to RENAME.COM that will
enable DOS to do this, too?
     Editor's Note:  This procedure does exactly as described using
both DOS 2.1 and 3.0, plus adding the flexibility of changing the
filename at the same time.  Not only can you move files, but if you
have DOS 3.0 you can even use the same procedure to rename directories,
something you can't do within DOS at all. For example, if you have a
first-level subdirectory named \TEXT, you can change its name to \GRAPH
by entering:
          NAME "\TEXT" AS "\GRAPH"
This is a neat trick, indeed.
     As for using the RENAME command in a similar manner, that simply
cannot be done.  Since RENAME is an intrinsic command, you would need
to alter COMMAND.COM to fix the problem, and we advise strongly against
trying that.

-----------------------------------------------------------------
                            Up a Tree
         (PC Magazine Vol 4 No 16 Aug 6, 1985 PC Tutor)

     If you are in one subdirectory and want to call a program in
another part of the tree the PATH option lets you to call a .EXE
or .BAT program file, but not any associated data or .OVL files needed
by the program.  For example, a PE.EXE program needs PE.PRO and both
are in the EDIT subdirectory, but PATH will only call the former.
     There are three possible solutions to this problem which has
plagued subdirectory users ever since DOS 2.0 was introduced.
     First, there are a number of public domain programs that extend
PATH command capability to include all file searches.  Thus, as the
program searches for overlay files, it will go to the correct
subdirectory.  Some of these programs may do strange things when you
try to create a file.
     Second, there are more sophisticated commercial programs
available that let you specify certain files that are to be found in
specific subdirectories.  This tends to make your environment list
pretty long, but it works.
     The third approach is to update to DOS 3.1 which contains a
program called SUBST that lets you section off a piece of your
subdirectory tree as a drive.  For example, if you enter:
          SUBST A: C: \EDIT
this would make the EDIT subdirectory accessible as drive A:, and
most programs search at least drive A: for required overlays.  If your
program can handle it, use a different drive designator (say E:) since
otherwise drive A: will become temporarily inaccessible for other use.
In this case, type:
          SUBST E: C: \EDIT

-----------------------------------------------------------------
                         Find that Path
             (PC World The Help Screen August 1985)

     The PC AT's hard disk presents a stubborn problem.  I would like
to place WordStar v3.3 in a word processing directory (\WP) and develop
six to eight subdirectories for text so that letters and other files
on a given topic may be kept together in a specific subdirectory.
Relying on a PATH command that includes the directory C:\WP, I have
tried to create a series of batch files that would change to the
directory containing the text I seek and then call WordStar.
     My efforts to access a working WordStar from any of the
subdirectories have failed.  After WordStar's copyright screen clears,
instead of the opening menu screen, "@@@@" appears in the upper left
corner of the screen.  Only after copying WS*.* into each subdirectory
can I edit documents.  I'm encountering similar problems with other
software.  Only 1-2-3 works, because it allows designation of a
subdirectory as well as a drive for storing worksheet files.

     Editor's Response:  Because you have an AT, I will assume you are
using DOS 3.0.  DOS 3.0 contains a file called VDISK.SYS which is a
device driver used to implement a RAM disk.  First create a small RAM
disk and copy a program's files to it.  Next change the current
directory of the hard disk drive to the one you want to hold your data
files.  Then make the RAM disk the default drive and call the program.
(The commands that perform these steps can be incorporated in a batch
file; in that case, you'd just call the batch file to implement the
instructions.)
     Although many popular programs do not recognize paths, most can
take advantage of a dual disk drive environment.  You can keep the
program's files in the current directory on one drive, usually drive
A:, and your data files in the current directory of another drive.
In this case we've substituted a RAM disk for drive A: and a
subdirectory of the hard disk for drive B:.  Many of these applications
also expect all program files, such as configuration files or overlay
files, to be either in the current directory of the default drive or
in drive A:.  Most, however, will allow you to change the drive that
the application assumes is holding its program files.
     WordStar is one such program, which is why it would not run until
its overlay files had been copied into the current subdirectory.  To
get WS.COM to look to the RAM disk for its overlays, use WordStar's
WINSTALL program to change the system disk drive (choice R on
WINSTALL's menu of WordStar features).  If an applications does not
let you choose a drive for its program files, use the command:
ASSIGN A:=d:, substituting the RAM disk drive letter for d.  After
exiting the application, issue the command ASSIGN to clear the prior
assignment and regain the use of drive A:.
     In either case, to change the subdirectories you must exit the
program and, either manually or via a batch file, use the DOS command
CD, then restart the program.
     DOS 3.1 includes a new external command, SUBST, which offers an
easier and more elegant solution for just this problem.  SUBST allows
you to assign a path to a drive specifier in much the same way that
ASSIGN redirects calls for one drive to another.
     A batch file such as the following allows an application to access
subdirectories by referencing the substituted drive letter and, when
the application is exited, to delete the substitutions:

SUBST B: C:\WP
SUBST D: C:\WP\LETTERS
SUBST E: C:\WP\MEMO
D:
B:WS %1
SUBST B:/D
SUBST D:/D
SUBST E:/D

     You will still need to install WordStar so that it looks to the
proper drive for its overlays (drive B: for his sample substitution),
unless you substitute drive A: for C:\WP.  In addition, to use drive
letters beyond E:, you must reboot with a CONFIG.SYS file that includes
the line LASTDRIVE=d:, where d is the last drive letter used by the
system.